13.5 KB · ⇊ 8 parts · ⤓ Micron 13.5 KB · ⤓ HTML 23.8 KB

top

Internet Control Message Protocol (ICMP, Protocole de message de contrôle sur Internet) est l’un des protocoles fondamentaux constituant la suite des protocoles Internet. C'est un protocole de couche réseau (couche no 3 du modèle OSI), au même niveau que le protocole Internet (IP). Le protocole IP ne gérant que le transport des paquets et ne permettant pas l'envoi de messages d'erreur, on lui associe ICMP pour contrôler les erreurs de transmission. ICMP permet de transporter des messages de contrôle et d’erreur pour qu'une machine émettrice sache qu'il y a eu un incident de réseau, par exemple lorsqu’un service ou un hôte est inaccessible. La commande Ping est un exemple d'application utilisant des messages de contrôle ICMP.

Cet article traite d’ICMP version 4 qui accompagne IPv4, détaillé dans la RFC 792cite-ref-rfc-792-1-0[1]. La version IPv6 du protocole, RFC 4443cite-ref-rfc-4443-t-d-2-0[2], est présentée dans l’article Internet Control Message Protocol V6.

• Format des paquets

• Les différents messages de contrôle

• Signification du type 4 (extinction de la source)

• Signification du type 5 (redirection)

• Failles dans le protocole ICMP

• Notes et références

• Voir aussi

• Article connexe

• Liens externes

Bien qu'il soit à un niveau équivalent au protocole IP (si l'on tente de rapprocher le modèle OSI au modèle TCP/IP), un paquet ICMP est néanmoins encapsulé dans un paquet IP. Dans le cadre de l'IPv4, la forme générale d'un tel paquet est la suivante :

| Bit 0 - 7 | Bit 8 - 15 | Bit 16 - 23 | Bit 24 - 31 |

|---|---|---|---|

| Version et IHL | Type de service | Longueur totale | Longueur totale |

| Identification (fragmentation) | Identification (fragmentation) | flags et offset (fragmentation) | flags et offset (fragmentation) |

| Durée de vie (TTL) | Protocole | Somme de contrôle de l'en-tête | Somme de contrôle de l'en-tête |

| Adresse IP source | Adresse IP source | Adresse IP source | Adresse IP source |

| Adresse IP destination | Adresse IP destination | Adresse IP destination | Adresse IP destination |

| Type de message | Code | Somme de contrôle | Somme de contrôle |

| Bourrage ou données | Bourrage ou données | Bourrage ou données | Bourrage ou données |

| Données ( optionnel et de longueur variable ) | Données ( optionnel et de longueur variable ) | Données ( optionnel et de longueur variable ) | Données ( optionnel et de longueur variable ) |

Avec :

• Un en-tête IP (en bleu), avec Version valant 4, Protocole valant 1 et Type de Service valant 0.

• Le type de message ICMP (8 bits).

• Le code de l'erreur (8 bits).

• Une somme de contrôle (16 bits), calculée sur la partie spécifique à ICMP (sans l'en-tête IP).

• Une partie (en jaune) aménagée pour des données relatives aux différents types de réponses (32 bits). Si elle n'est pas utilisée, on procède à un bourrage (cette partie peut correspondre aux Identifiant et Numéro de séquence pour un paquet de type Ping par exemple, pour plus d'informations se référer à la RFC 792cite-ref-rfc-792-1-1[1] cite-ref-3[3])

• Le message à transmettre (en jaune)

Les différents incidents possibles sont reportés ci-dessous, avec le type de message et le code d'erreur correspondant.

| Type | Code | Description |

|---|---|---|

| 0 - Réponse d'echo | | Réponse d'ECHO (Réponse au message de type 8) |

| 1 et 2 - Réservés | | Reservés |

| 3 – Destinataire inaccessible | 0 | Le réseau n'est pas accessible |

| 3 – Destinataire inaccessible | 1 | La machine n'est pas accessible |

| 3 – Destinataire inaccessible | 2 | Le protocole n'est pas accessible |

| 3 – Destinataire inaccessible | 3 | Le port n'est pas accessible |

| 3 – Destinataire inaccessible | 4 | Fragmentation nécessaire mais impossible à cause du drapeau ( flag ) DF |

| 3 – Destinataire inaccessible | 5 | Le routage a échoué |

| 3 – Destinataire inaccessible | 6 | Réseau inconnu |

| 3 – Destinataire inaccessible | 7 | Machine inconnue |

| 3 – Destinataire inaccessible | 8 | Machine non connectée au réseau (inutilisé) |

| 3 – Destinataire inaccessible | 9 | Communication avec le réseau interdite |

| 3 – Destinataire inaccessible | 10 | Communication avec la machine interdite |

| 3 – Destinataire inaccessible | 11 | Réseau inaccessible pour ce service |

| 3 – Destinataire inaccessible | 12 | Machine inaccessible pour ce service |

| 3 – Destinataire inaccessible | 13 | Communication interdite (filtrage) |

| 3 – Destinataire inaccessible | 14 | Priorité d'hôte violée |

| 3 – Destinataire inaccessible | 15 | Limite de priorité atteinte |

| 4 – Extinction de la source | 0 | Extinction de la source ( source quench ) |

| 5 – Redirection | 0 | Redirection pour un réseau |

| 5 – Redirection | 1 | Redirection pour un hôte |

| 5 – Redirection | 2 | Redirection pour un réseau et un service |

| 5 – Redirection | 3 | Redirection pour un hôte et un service |

| 8 – Demande d'echo | 0 | Demande d'ECHO (utilisé par la commande ping ) |

| 11 – Temps dépassé | 0 | Temps de vie du datagramme dépassé |

| 11 – Temps dépassé | 1 | Temps de ré-assemblage des fragments du datagramme dépassé |

| 12 – En-tête erroné | 0 | Le pointeur indique l'erreur |

| 12 – En-tête erroné | 1 | Absence d'une option obligatoire |

| 12 – En-tête erroné | 2 | Mauvaise longueur |

| 13 – Demande heure | 0 | Timestamp request |

| 14 – Réponse heure | 0 | Timestamp reply |

| 15 – Demande adresse IP | 0 | Demande d'adresse réseau |

| 16 – Réponse adresse IP | 0 | Réponse d'adresse réseau |

| 17 – Demande masque sous-réseau | 0 | Demande de masque de sous-réseau |

| 18 – Réponse masque sous-réseau | 0 | Réponse de masque de sous-réseau |

Un routeur de transit ou la machine d'extrémité demande à l'émetteur de ralentir le rythme des envois de trame. Les routeurs de transit stockent les trames reçues dans un tampon (buffer) avant de les router (store and forward). Si ce tampon venait à être plein ou si la charge CPU du routeur dépassait un seuil (ou toute autre motif de congestion) il ne pourrait plus assumer le routage des paquets à venir. Ils seraient alors perdus silencieusement. Afin que cela ne se produise pas, n'importe quel nœud de transit peut ainsi informer l'émetteur de ralentir la cadence. Et cela pour n'importe quel protocole de la couche 4 (UDP, TCP…).

Ce mécanisme n'est pas redondant avec celui d'annonce de la taille de la fenêtre glissante d'une connexion TCP car cette dernière ne peut être contrôlée que par le destinataire (sauf proxification) or ici il s'agit des routeurs de transit.

Ce type de message a été rendu obsolète par la RFC 6633cite-ref-rfc-6633-t-d-4-0[4] en 2012.

Le routeur remarque que la route qu'a choisie l'ordinateur émetteur n'est pas optimale car le prochain routeur à passer pour atteindre le destinataire se trouve sur le même réseau que celui de l'ordinateur émetteur. Le routeur envoie l'adresse du prochain routeur à ajouter dans la table de routage de l'ordinateur émetteur de façon que le prochain envoi vers le même destinataire ne passe pas inutilement par lui. Cette option est souvent bloquée dans les réseaux des entreprises parce qu'elle peut être utilisée par un attaquant pour rediriger le flux de données d'une victime vers sa propre machine.

Il existe plusieurs attaques connues contre ICMPcite-ref-5[5]cite-ref-6[6]cite-ref-7[7]. Parmi elles, on peut citer :

• ICMP Sweep : En envoyant une série de requêtes ICMP sur un réseau, il est possible d'analyser les réponses et en déduire la structure.

• ICMP Redirect : Les messages ICMP de type 5 (redirection) peuvent être utilisés de manière malhonnête pour traverser un pare-feu. L'attaque consiste à faire passer un ordinateur par un chemin détourné qui va éviter le pare-feu. La solution consiste à configurer l'ordinateur pour ignorer ce genre de message.

• Les messages ICMP de type 3 pour les codes 2 ou 3 (voire 4) peuvent clore une connexion TCP.

• Un envoi répété de message ICMP de type 4 (code 0) ralentit grandement le débit d'une connexion.

• Le message ICMP de type 3 pour le code 4 ralentit une connexion en passant le MTU au minimum (68 octets) puis en l'augmentant progressivement.

cite-note-rfc-792-11. (en) Request for comments no 792

cite-note-rfc-4443-t-d-22. ↑ (en) « Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification », Request for comments no 4443, Mars 2006

cite-note-33. ↑ Internet Control Message Protocol

cite-note-rfc-6633-t-d-44. ↑ (en) « Deprecation of ICMP Source Quench Messages », Request for comments no 6633, mai 2012

cite-note-55. ↑ 2001« ICMP Attacks Illustrated », sur www.sans.org, 2001 (consulté le 6 janvier 2016)

cite-note-66. ↑ baltatulioymainomazzocchi2000madalina-baltatuantonio-lioyfabio-mainodaniele-mazzocchi2000Madalina Baltatu, Antonio Lioy, Fabio Maino et Daniele Mazzocchi, « Security issues in control, management and routing protocols », Computer Networks, pioneering Tomorrow's Internet: Selected papers from the TARENA Networking Conference 2000, vol. 34,‎ 1er décembre 2000, p. 881-894 (DOI 10.1016/S1389-1286(00)00159-6, lire en ligne, consulté le 6 janvier 2016)

cite-note-77. ↑ OpenBSD KernelTrap article

• Protocole réseau passant difficilement les pare-feu

• rfc792(en) « RFC792 : Internet Control Message Protocol », septembre 1981

• 1122(en) « RFC1122 : Requirements for Internet Hosts -- Communication Layers », juillet 1989

• (en) IANA ICMP Parameters liste complète des types et codes ICMP

• (fr) Failles ICMP découvertes par Fernando Gont et l'histoire des brevets avec Cisco

• Portail de l’informatique

• Portail des télécommunications